Packet-based communication networks may utilize flow-based packet forwarding techniques such that different traffic flows may be transported over different paths. For example, an upstream packet flow and a downstream packet flow between the same network nodes may be transported over different network paths for various reasons, e.g., packet processing requirements, available link capacity, etc. Flow-based packet forwarding techniques may forward packet flows over traffic engineered (TE) paths to meet quality of service (QoS) requirements of the packet flows. In addition, flow-based packet forwarding techniques may forward traffic flows through packet-processing elements or nodes that perform specialized processing (e.g., firewall, encryption, compression) on packets in the traffic flows.
In a conventional packet-based network using the Internet Protocol version 6 (IPv6), various fields in the IP packet header such as the flow label and traffic class may to used to determine how a packet should be treated by network nodes that receive the packet. However these fields only have significance in one direction (e.g. from Node A to Node B) and cannot be used to affect the path and the treatment of flows travelling in the reverse direction (e.g. from Node B to Node A). In addition, these fields may be changed anywhere along the path from the packet source to its destination, and therefore may not be preserved across the entire end-to-end path.
In a conventional packet-based network, a device must acquire a new IP address whenever it changes its point of attachment. This may incur a significant amount of signaling overhead. In addition, this can disrupt any existing packet flows in progress that are associated with an old IP address.
In a conventional mobile environment where a device may move from one network attachment point to another without changing its IP address, additional information such as a tunnel header may need to be attached to a packet to ensure that the packet is forwarded from a network ingress node to the network attachment point currently used by the device. Tunneling solutions such as those using the Proxy Mobile Internet Protocol version 6 (PMIPv6) require maintenance of tunnel context at the tunnel end points, require control signaling between the tunnel end points, introduce tunnel packet overheads, encapsulate all flows addressed to a particular device or device interface within the same tunnel, and force all flows addressed to a particular device or device interface to be routed through the same network ingress/egress node. Some variants of these protocols support encapsulation of different packet flows within different tunnels but these solutions incur a commensurate increase in the number of tunnel addresses that must be allocated, in the amount of context information that must be maintain by the tunnel end points, and in the amount of signaling that must be exchanged between the tunnel end points.
Therefore there exists a need to reduce the overheads associated with forwarding packets in a mobile environment while, at the same time, enabling flow-specific treatment of packets in order to meet QoS and service-specific processing requirements.